In conventional wireless communication systems, such as wideband code division multiple access (WCDMA) Release 5/6, high speed data transmission is achieved by means of high speed downlink packet access (HSDPA) and high speed uplink packet access (HSUPA) technologies. To improve reliability of data transmission, H-ARQ and automatic repeat request (ARQ) are implemented.
H-ARQ and ARQ employ a mechanism to send feedback in the form of a positive acknowledgment (ACK) or a negative acknowledgement (NACK) that respectively indicate successful or unsuccessful receipt of a data packet to a transmitter so that the transmitter may retransmit a failed packet.
In implementing H-ARQ, H-ARQ errors may occur, such as a NACK-to-ACK error, a discontinuous transmission (DTX)-to-ACK error, a buffer corruption error, or the like. The NACK-to-ACK error occurs when a NACK that is sent by a receiver is misinterpreted as an ACK by a transmitter. The DTX-to-ACK error occurs when a DTX special burst transmitted by the receiver is misinterpreted as an ACK by the transmitter. The buffer corruption error occurs when the receiver does not detect a change of packets, (e.g., due to new data indicator (NDI) errors), and combines an old packet with a new different packet, giving rise to memory or buffer corruption.
Several solutions have been proposed to decrease the H-ARQ errors and increase the robustness of the H-ARQ retransmission scheme with respect to error detection, error signaling and error recovery. For error detection, (e.g., detection of a NACK-to-ACK error), an H-ARQ receiver assumes a NACK-to-ACK error if the H-ARQ receiver receives a new transmission while it expects a retransmission. Alternatively, the H-ARQ transmitter assists the H-ARQ receiver in detecting errors by including a ‘cause value’ along with the transmitted packet to indicate the cause of the previous H-ARQ termination, (e.g., a cause value of ‘0’ indicates that the previous H-ARQ termination is because of ACK reception, and a cause value of ‘1’ indicates that the previous H-ARQ termination is not because of ACK reception, but because of the maximum retransmission limit).
For error signaling, once the H-ARQ receiver detects a potential NACK-to-ACK error, the H-ARQ receiver informs the H-ARQ of the error, (i.e., sends a NACK-to-ACK error indication or an error report in general).
For error recovery, once the H-ARQ transmitter receives the error report, the H-ARQ transmitter notifies the ARQ transmitter by sending a local NACK. This assumes that a timer mechanism is utilized before the local ACK can be generated by the H-ARQ transmitter, which can allow a potential error report to be received within the timer's timeout value, as illustrated in FIG. 1. Once the ARQ transmitter receives the local NACK, the ARQ transmitter can recover the lost packet through ARQ retransmission.
FIG. 1 shows an H-ARQ-assisted ARQ operation proposed for third generation partnership project (3GPP) standards. A transmitter 150 includes an ARQ transmitter 152 and an H-ARQ transmitter 154. A receiver 160 includes an ARQ receiver 162 and an H-ARQ receiver 164. In that proposal, the H-ARQ transmitter 154 provides a local ACK or a local NACK to the ARQ transmitter 152.
A local NACK is generated when the H-ARQ transmitter 154 fails the H-ARQ transmission, (e.g., due to maximum retransmission limit). The ARQ transmitter 152 sends a protocol data unit (PDU) x to the H-ARQ transmitter 154 (step 102). The H-ARQ transmitter 154 sends the PDU x to the H-ARQ receiver 164 (step 104). The PDU x is not decodable and the H-ARQ receiver 164 sends a NACK to the H-ARQ transmitter 154 (step 106). The H-ARQ transmitter 154 retransmits the PDU x to the H-ARQ receiver 164 (step 108). The PDU x is still not decodable and the H-ARQ receiver 164 sends another NACK to the H-ARQ transmitter 154 (step 110). At such point, it is determined that the number of retransmissions for the PDU x reaches a maximum retransmission limit (step 112). The H-ARQ transmitter 154 then sends a local NACK to the ARQ transmitter 152 (step 114).
A local NACK is also generated when an NACK-to-ACK error is reported from the H-ARQ receiver 164 to the H-ARQ transmitter 154. The ARQ transmitter 152 sends a PDU y to the H-ARQ transmitter 154 (step 116). The H-ARQ transmitter 154 transmits the PDU y to the H-ARQ receiver 164 (step 118). The PDU y is not decodable and the H-ARQ receiver 164 sends a NACK to the H-ARQ transmitter 154 (step 120). However, the NACK is misinterpreted as an ACK by the H-ARQ transmitter 154 and the H-ARQ transmitter 154 treats the PCU y as successfully transmitted. The H-ARQ receiver 164 detects an NACK-to-ACK error, (e.g., when the H-ARQ receiver 164 receives a new PDU via the same H-ARQ process while waiting for retransmission of the PDU y), (step 122). The H-ARQ receiver 164 sends a NACK-to-ACK error indicator to the H-ARQ transmitter 154 (step 124). Upon receipt of the NACK-to-ACK error indicator, the H-ARQ transmitter 154 sends a local NACK to the ARQ transmitter 152 and the failed packet is recovered at an ARQ level (step 126).
A local ACK is generated when none of the above two events for an ARQ packet occurs during a predefined time interval. The ARQ transmitter 152 sends a PDU z to the H-ARQ transmitter 154 (step 128). The H-ARQ transmitter 154 transmits the PDU z to the H-ARQ receiver 164 (step 130). The PDU z is successfully decoded and the H-ARQ receiver 164 sends the PDU z to the ARQ receiver 162 and sends an ACK to the H-ARQ transmitter 154 (steps 132, 134). When it is determined that a NACK-to-ACK error is not reported during a predetermined time interval (step 136), the H-ARQ transmitter 154 sends a local ACK to the ARQ transmitter 152 (step 138). The ARQ transmitter 152 will discard the packet from a transmit buffer after receiving the local ACK from the H-ARQ transmitter 154.
There are two modes of H-ARQ operations, synchronous H-ARQ and asynchronous H-ARQ. Synchronous H-ARQ refers to conducting packet retransmissions in a synchronous manner based on a predetermined timing relation. Asynchronous H-ARQ refers to conducting packet retransmissions in a flexible manner that is not constrained by a specific timing relationship. In adaptive H-ARQ, the transmission format, (e.g., data modulation, channel coding rate, and assigned resource blocks), may be changed adaptively between the initial transmission and retransmissions.
Currently, both synchronous and asynchronous H-ARQ modes are being considered for evolved universal terrestrial radio access (UTRA+) and long term evolution (LTE) of 3GPP, but only one mode is to be supported in a single direction, (i.e., uplink or downlink). Due to multimedia broadcast multicast services (MBMS) and persistent scheduling for real-time service, (such as voice over IP (VoIP)), delay may be caused for some H-ARQ retransmissions.
In the downlink, if MBMS is multiplexed with unicast in a time division multiplexing (TDM) manner, both synchronous and asynchronous H-ARQ will have extra retransmission delay caused by sub-frames occupied by MBMS. FIGS. 2A and 2B show the impact of MBMS on the retransmission for asynchronous or synchronous H-ARQ transmissions, respectively. In these examples, the minimum retransmission interval is assumed to be six (6) subframes. In FIG. 2A (asynchronous H-ARQ), the H-ARQ retransmission at subframe 6 is conflict with MBMS transmissions and should be rescheduled to subframe 7. In FIG. 2B (synchronous H-ARQ), a packet is initially transmitted at subframe 0 and scheduled to be retransmitted at subframe 6. However, subframes 2-6 are occupied by MBMS data transmission and the H-ARQ retransmission should be rescheduled to the next available subframe, (subframe 12).
Both in the uplink and the downlink, for the services with frequent transmissions of small packets at regular intervals such as VoIP, long-term fixed resource allocation, (i.e., persistent scheduling), is performed in order to reduce the control signaling overhead. However, when synchronous H-ARQ is implemented with persistent scheduling, some of the retransmissions are restricted due to the long-term fixed resource allocation. FIGS. 3A and 3B show conflicts of synchronous H-ARQ transmissions with persistent scheduling. Either a retransmission of a normal scheduled user or a retransmission of a persistent scheduled user is given a priority and the other should be delayed. FIG. 3A shows the case that a persistent scheduled user is given a priority and FIG. 3B shows the case that a normal scheduled user is given priority.
FIG. 4 shows problems of synchronous H-ARQ transmissions with adaptive transmission time interval (TTI). Assuming a variable retransmission interval according to the TTI length, in synchronous H-ARQ, it is not possible to retransmit a packet after the retransmission interval when a different TTI length is accommodated within a radio frame. In FIG. 4, a first packet is assigned a short TTI (1 subframe) and a second packet is assigned a long TTI (2 subframes). The first frame is initially transmitted at subframe 2 and scheduled to be retransmitted with an interval of 6 subframes thereafter, (i.e., subframes 8, 14, 20, . . . ). The second frame is transmitted at subframes 5 and 6 and scheduled to be retransmitted with an interval of 6 frames thereafter, (i.e., subframes 12, 13, 19, 20, . . . ). At subframe 20, a conflict occurs and one of them should be rescheduled.
Therefore, it would be desirable to provide more efficient and robust solutions for supporting synchronous and/or asynchronous H-ARQ operations.